Redis的主从复制模式下,一旦主节点由于故障不能提供服务,需要人工将从节点晋升为主节点,同时还要通知应用方更新主节点地址,对于很多应用场景这种故障处理的方式是无法接受的。 Redis从2.8开始正式提供了Redis Sentinel(哨兵)架构来解决这个问题,Redis Sentinel是Redis的高可用实现方案,在实际的生产环境中,对提高整个系统的高可用性是非常有帮助的。
主从复制的问题
主从解决的问题 - 如果主节点出故障了,从节点可以作为后备力量顶上来,保证了数据的一致性 - 从节点拓展了主节点的读能力,主节点如果支撑不住,从节点会帮助主节点分担压力 主从可能出现的问题 - 一旦主节点出现故障,需要手动将从节点晋升为主节点,然后将其他从节点的主节点配置改为这个,需要人工干预 - 主节点所只能在一台主机,限制了主节点的写能力 - 主节点只能在一台主机,存储能力受到单机的限制
Redis Sentinel的高可用性
Redis Sentinel是一个分布式架构,其中包含若干个Sentinel节点和Redis数据节点,每个Sentinel节点会对数据节点和其余Sentinel节点进行监控,当它发现节点不可达时,会对节点做下线标识。如果被标识的是主节点,它还会和其他Sentinel节点进行“协商”,当大多数Sentinel节点都认为主节点不可达时,它们会选举出一个Sentinel节点来完成自动故障转移的工作,同时会将这个变化实时通知给Redis应用方。整个过程完全是自动的,不需要人工来介入,所以这套方案很有效地解决了Redis的高可用问题
主从复制模式
Redis-sentinel架构
安装和部署
先画个拓扑图,接下来就按照这个拓扑图为例完成部署
简要说明,会开启6379、6666和7777三个端口的Redis实例,其中6379默认配置的为主节点,6666和7777为从节点,配置三个Sentinel节点端口分别是26379、26666和27777,下面进行详细说明:
启动主节点
1 | [root@vmzq1l0l ~]# redis-cli |
启动两个从节点
用配置文件的方式启动,复制不同配置文件改相关配置(下面以6666端口实例举例,7777操作完全相同,只是配置从6666改为7777)
1 | cp redis.conf redis-6666.conf |
需要修改redis-6666.conf文件的以下配置(由于种种原因在5.0以后比较新的版本中,原本配置中slaveof改成了replicaof,会依然保留slaveof命令,本篇使用的是5.0.3版本)
1 | #端口号 |
启动两个实例(7777实例的配置文件按照上述套路再次执行一遍改成7777的配置)
1 | redis-server redis-6666.conf |
如果上述步骤没问题的话,现在看看主节点的主从信息
1 | [root@vmzq1l0l redis]# redis-cli info replication |
6666端口实例从节点的主从信息
1 | [root@vmzq1l0l redis]# redis-cli -h 127.0.0.1 -p 6666 info replication |
至此只是完成了一主两从的主从配置
部署Redis Sentinel节点
配置Sentinel节点
redis安装目录下有个sentinel.conf这个配置文件,默认是26379端口,修改以下配置参数:
1 | port 26379 |
- sentinel monitor mymaster 127.0.0.1 6379 2配置代表sentinel节点需要监控127.0.0.1:6379这个主节点,2代表判断主节点失败至少需要2个Sentinel节点同意,mymaster是主节点的别名
- down-after-milliseconds 选项指定了 Sentinel 认为服务器已经断线所需的毫秒数
- parallel-syncs 选项指定了在执行故障转移时, 最多可以有多少个从服务器同时对新的主服务器进行同步, 这个数字越小, 完成故障转移所需的时间就越长
启动Sentinel节点
方法一,使用redis-sentinel命令:
1 | redis-sentinel sentinel.conf |
方法二,使用redis-server命令加–sentinel参数:
1 | redis-server sentinel.conf --sentinel |
两种方法本质上是一样的。